…label on startup (#3307)

## Why make this change?

Closes #3269

## What is this change?

Align the CLI logger labels with the labels used in ASP.Net Core.
Downgraded internal plumbing message from `Information` to `Debug`

Add a test case to cover the changed behavior.

## How was this tested?

Added a test case to validate the new behavior.

(cherry picked from commit 75b8eec)

…n and startup (#3321)

## Why make this change?

Closes #3271

## What is this change?

Previously, child configs were defaulting to `throw` for their exception
behavior during deserialization, but parent configs correctly use
`ignore`. We align this behavior. Furthermore, during startup of the
engine we throw an exception if a child config itself can not be loaded,
halting startup, as would happen with the parent.

When a child config file exists but fails to load, a generic diagnostic
message is surfaced: `"Failed to load datasource file: {path}. Ensure
the file is accessible and contains a valid DAB configuration."` —
covering all failure modes including invalid JSON, IO errors, and
permission issues.

## How was this tested?

Added 2 new tests:
1. `ChildConfigWithMissingEnvVarsLoadsSuccessfully` — verifies that a
child config with unresolved `@env()` references loads successfully (env
vars saved and restored in `finally`; uses unique temp file path)
2. `ChildConfigLoadFailureHaltsParentConfigLoading` — verifies that a
child config file that exists but contains invalid JSON causes parent
config loading to fail (saves/restores `Console.Error` and disposes
`StringWriter` in `finally`; uses unique temp file path)

Updated `TestLoadRuntimeConfigSubFilesFails` to assert that non-existent
child config files are gracefully skipped (not treated as failures).

- [x] Unit Tests

---------

Co-authored-by: Souvik Ghosh <souvikofficial04@gmail.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
(cherry picked from commit c014e52)

## Why make this change?

Closes #3261

## What is this change?

In the `RestController`, add descriptive messaging for `NotFound()` when
role is missing. Add a test case to cover this new behavior.

## How was this tested?

Test case added.

Manually verified the endpoint provided the correct response.

<img width="566" height="193" alt="image"
src="https://github.com/user-attachments/assets/e0549b70-b605-4ddc-a5d4-a107a91361ea"
/>

## Sample Request(s)

Can manually verify by going to this endpoint without a "foo" role
defined.

`https://localhost:5001/rest/openapi/foo`

---------

Co-authored-by: Souvik Ghosh <souvikofficial04@gmail.com>
(cherry picked from commit 5fa2bfc)

## Why make this change?

Closes #3397

## What is this change?

When `DeterminePatchPutSemantics` threw a `DataApiBuilderException` for
an invalid `If-Match` value, the exception was thrown before entering
`HandleOperation` and the `try-catch` block within. This is where we
convert `DataApiBuilderException` into structured JSON error response.
We therefore move the `DeterminePatchPutSemantics` call inside of the
`try-catch` block within `HandleOperation`, gating the function behind a
check of the operation type so that it only applies to `Upsert` and
`UpsertIncremental` operations.

## How was this tested?

Added a test for `Put` and a test for `Patch` to validate the new
behavior.

## Sample Request(s)

Any valid `Put` or `Patch` with headers using `If-Match` with a value
other than `*`

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
(cherry picked from commit 0cb58f0)

## Why make this change?

Closes #3268

## What is this change?

When `dab validate` or `dab start` encounters a config parsing error
(e.g. missing entities/autoentities), the CLI previously dumped the full
exception message and stack trace to stderr. This made the output noisy
and unhelpful. After this change, only a clean, descriptive validation
message is shown.

The key design changes:

- `TryParseConfig` is now a pure function that returns an `out string?
parseError` message on failure instead of writing to `Console.Error` or
`ILogger` internally. Error reporting is the caller's responsibility.
- `FileSystemRuntimeConfigLoader.TryLoadConfig` writes the `parseError`
to `Console.Error` (because config is parsed before the DI container and
logger are available, so the log buffer would never be flushed on a
parse failure) and sets an instance-scoped `IsParseErrorEmitted` flag so
CLI callers (`ConfigGenerator`) can avoid logging duplicate messages.
- `ConfigGenerator.IsConfigValid` now has an explicit early-return path
when config parsing fails (via `runtimeConfigProvider.TryGetConfig`),
using `IsParseErrorEmitted` to suppress duplicate output.
- `ValidateOptions.Handler` uses `LogError("Config is invalid.")`.
- Comments referencing which method emits the error to `Console.Error`
corrected to `TryLoadConfig` (not `TryParseConfig`).

## How was this tested?

* `ValidateConfigTests.cs` — Added
`TestValidateConfigWithNoEntitiesProducesCleanError` (new test verifying
clean error message, no stack traces).
* `EnvironmentTests.cs` — Updated
`FailureToStartEngineWhenEnvVarNamedWrong` to match the new single-line
clean stderr format.
* `EndToEndTests.cs` — Simplified assertions in
`TestExitOfRuntimeEngineWithInvalidConfig` (this test is Ignored but
updated for consistency).
* `RuntimeConfigLoaderTests.cs` — Updated
`FailLoadMultiDataSourceConfigDuplicateEntities` to assert
`loader.IsParseErrorEmitted` is true.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Souvik Ghosh <souvikofficial04@gmail.com>
(cherry picked from commit f2b4cbd)

…strict is false (#3325)

## Why make this change?

Closes #3260

## What is this change?

When request-body-strict is set to false, the OpenAPI document was still
generating separate _NoAutoPK and _NoPK component schemas for each
entity. These schemas only differ from the base entity schema by
excluding primary key fields, a distinction that is meaningless when the
request body already allows additional properties. This made the
generated OpenAPI document unnecessarily verbose and confusing for
consumers.

The `isRequestBodyStrict` flag is now threaded through `BuildPaths` and
`CreateOperations` so that POST/PUT/PATCH request body schema references
point to the base entity schema when strict mode is off. The
`CreateComponentSchemas` method now gates `_NoAutoPK` and `_NoPK` schema
generation on strict mode, and its XML documentation has been updated to
accurately describe both strict and non-strict behavior.

## How was this tested?

- [ ] Integration Tests
- [x] Unit Tests

Updated existing unit test
`RequestBodyStrict_False_OmitsRedundantSchemas` (renamed from
`RequestBodyStrict_False_AllowsExtraFields`) to verify that when
request-body-strict is false:
- `_NoAutoPK` and `_NoPK` component schemas are not generated.
- The base entity schema is still present.
- POST/PUT/PATCH operations reference the base entity schema (not
`_NoAutoPK` or `_NoPK`).

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
Co-authored-by: Anusha Kolan <anushakolan10@gmail.com>
(cherry picked from commit c860fc5)

## Why make this change?

Closes #3324

## What is this change?

Expand the enums for our json data type to include `integer`. Use this
new integer type in the system to json type map.

## How was this tested?

Existing test coverage.

---------

Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
(cherry picked from commit 062ddc6)

## Why make this change?

Closes #3267

## What is this change?

Alters the validation logic in the following way.

Is top-level config with data-source-files? (we call this a `Root`
config file)
├── YES
│ ├── Has datasource? → ValidateEntityPresence (same rules as non-root)
│   ├── No datasource but has entities/autoentities? → ERROR
│   └── No datasource, no entities → VALID (children provide everything)
│   └── For each child → ValidateNonRootConfig(child, filename)
│
└── NO (standalone or child config)
    ├── No datasource? → ERROR: "data source is required"
    └── Has datasource → ValidateEntityPresence

Note: A top-level config file without any children data-source files is
NOT considered a root. And an intermediary config file, ie: is a child,
that also has child configs is NOT a root. Only a top-level config with
children configs is a Root.

#### ValidateEntityPresence
Count resolved autoentities from AutoentityResolutionCounts
total = manual entities + resolved autoentities

total == 0? → ERROR: "No entities found"
total > 0 but autoentities discovered nothing? → WARN: "Autoentities
configured but none discovered"

No double messaging. If total is 0, only the error is recorded, not the
warning.

## How was this tested?

### Truth table — top-level config

Variables (`1` = present / non-empty, `0` = absent / empty):
- **DSF** — `data-source-files` present
- **DS** — `data-source` present
- **E** — manual `entities` count > 0
- **AE** — `autoentities` count > 0 (presence, *not* resolved count)

Path is determined by `IsRootConfig = (DSF == 1) && !IsChildConfig`.

| # | DSF | DS | E | AE | AE resolved | Path | Expected | Test |
|---|:---:|:--:|:-:|:--:|:-----------:|------|----------|------|
| 1 | 0 | 0 | 0 | 0 | — | Non-root | **Error**: "data source is
required" | `TestNonRootWithNoDataSourceProducesError` |
| 2 | 0 | 0 | 0 | 1 | — | Non-root | **Error**: "data source is
required" | _covered by #1 — DS check fires first_ |
| 3 | 0 | 0 | 1 | 0 | — | Non-root | **Error**: "data source is
required" | _covered by #1_ |
| 4 | 0 | 0 | 1 | 1 | — | Non-root | **Error**: "data source is
required" | _covered by #1_ |
| 5 | 0 | 1 | 0 | 0 | — | Non-root | **Error**: "No entities found" |
`TestNonRootWithDataSourceAndNoEntitiesProducesError` |
| 6a | 0 | 1 | 0 | 1 | 0 | Non-root | **Error**: "No entities found" |
`TestNonRootWithDataSourceAndAutoentitiesResolvingZeroProducesError` |
| 6b | 0 | 1 | 0 | 1 | >0 | Non-root | **Valid** |
`TestNonRootWithDataSourceAndAutoentitiesResolvingEntitiesIsValid` |
| 7 | 0 | 1 | 1 | 0 | — | Non-root | **Valid** |
`TestNonRootWithDataSourceAndEntitiesIsValid` |
| 8a | 0 | 1 | 1 | 1 | 0 | Non-root | **Valid** + **Warn** |
`TestNonRootWithEntitiesAndAutoentitiesResolvingZeroLogsWarning` |
| 8b | 0 | 1 | 1 | 1 | >0 | Non-root | **Valid** | _covered by #7 / #6b
combined_ |
| 9 | 1 | 0 | 0 | 0 | — | Root | **Valid** (children carry the load) |
`TestRootWithNoDataSourceAndNoEntitiesIsValid`,
`TestRootConfigWithNoDataSourceAndNoEntitiesParses` |
| 10 | 1 | 0 | 0 | 1 | — | Root | **Error**: "must not define entities
or autoentities" |
`TestRootWithNoDataSourceButAutoentitiesProducesError` |
| 11 | 1 | 0 | 1 | 0 | — | Root | **Error**: "must not define entities"
| `TestRootWithNoDataSourceButEntitiesProducesError` |
| 12 | 1 | 0 | 1 | 1 | — | Root | **Error** | _covered by #11_ |
| 13 | 1 | 1 | 0 | 0 | — | Root (with own DS) | **Error**: "No entities
found" | `TestRootWithDataSourceAndNoEntitiesProducesError` |
| 14a | 1 | 1 | 0 | 1 | 0 | Root (with own DS) | **Error**: "No entities
found" |
`TestRootWithDataSourceAndAutoentitiesResolvingZeroProducesError` |
| 14b | 1 | 1 | 0 | 1 | >0 | Root (with own DS) | **Valid** |
`TestRootWithDataSourceAndAutoentitiesResolvingEntitiesIsValid` |
| 15 | 1 | 1 | 1 | 0 | — | Root (with own DS) | **Valid** |
`TestRootWithDataSourceAndEntitiesIsValid` |
| 16a | 1 | 1 | 1 | 1 | 0 | Root (with own DS) | **Valid** + **Warn** |
`TestRootWithEntitiesAndAutoentitiesResolvingZeroLogsWarning` |
| 16b | 1 | 1 | 1 | 1 | >0 | Root (with own DS) | **Valid** | _covered
by #15 / #14b combined_ |

### Truth table — child config (validated when iterating
`root.ChildConfigs`)

Children are always treated as non-root regardless of their own
`data-source-files`.

| # | DS | E | AE | AE resolved | Expected | Test |
|---|:--:|:-:|:--:|:-----------:|----------|------|
| C1 | 0 | 0 | 0 | — | **Error** naming the child file: "data source is
required" | `TestChildWithNoDataSourceProducesNamedError` |
| C2 | 0 | * | * | — | **Error** naming the child file: "data source is
required" | _covered by C1_ |
| C3 | 1 | 0 | 0 | — | **Error** naming the child file: "No entities
found" | `TestChildWithDataSourceAndNoEntitiesProducesNamedError` |
| C4a | 1 | 0 | 1 | 0 | **Error** naming the child file: "No entities
found" |
`TestChildWithDataSourceAndAutoentitiesResolvingZeroProducesNamedError`
|
| C4b | 1 | 0 | 1 | >0 | **Valid** | _covered by C5 (resolved entities
behave the same as manual entities)_ |
| C5 | 1 | 1 | 0 | — | **Valid** | _implicitly via
`TestRootWithDataSourceAndEntitiesIsValid` setup_ |
| C6a | 1 | 1 | 1 | 0 | **Valid** + **Warn** naming the child file |
`TestChildWithEntitiesAndAutoentitiesResolvingZeroLogsNamedWarning` |
| C6b | 1 | 1 | 1 | >0 | **Valid** | _covered by C5_ |

### Other scenarios

| Scenario | Expected | Test |
|----------|----------|------|
| Connection-string error gates entity validation (no entity error fires
when DB unreachable) | `IsConfigValid == false` due to connection error
only | `TestValidateNonRootZeroEntitiesWithInvalidConnectionString` |
| Config with no entities parses cleanly (constructor no longer throws)
and `IsConfigValid` returns false without throwing | parse OK, validate
fails | `TestValidateConfigWithNoEntitiesProducesCleanError`
_(modified)_ |
| Root parses successfully without a data source | parse OK,
`IsRootConfig == true` |
`TestRootConfigWithNoDataSourceAndNoEntitiesParses` |
| Non-root with DS and no entities parses successfully | parse OK,
`IsRootConfig == false` |
`TestNonRootConfigWithDataSourceAndNoEntitiesParses` |
| Autoentities present but resolve to nothing — must not crash, must not
double-message with "No entities found" | no crash; only "No entities
found" if total = 0 | `ValidateAutoentitiesConfiguration` _(modified to
`isValidateOnly: true`)_ |

New tests:

`TestRootConfigWithNoDataSourceAndNoEntitiesParses` Root config (has
data-source-files) without datasource parses OK
`TestNonRootConfigWithDataSourceAndNoEntitiesParses` Non-root config
with datasource + no entities parses OK (validation catches it later)
`TestNonRootWithDataSourceAndNoEntitiesProducesError` Calls
ValidateDataSourceAndEntityPresence directly, error recorded
`TestNonRootWithNoDataSourceProducesError` No datasource, error with
"data source is required"
`TestNonRootWithDataSourceAndEntitiesIsValid` Datasource + entities, no
errors
`TestRootWithNoDataSourceAndNoEntitiesIsValid` Root with child, no own
datasource, valid
`TestRootWithNoDataSourceButEntitiesProducesError` Root with entities
but no datasource, error
`TestRootWithDataSourceAndEntitiesIsValid` Root with own datasource +
entities, valid
`TestChildWithDataSourceAndNoEntitiesProducesNamedError` Child with no
entities, error names the child file
`TestChildWithNoDataSourceProducesNamedError` Child with no datasource,
error names the child file
`TestNonRootWithDataSourceAndAutoentitiesResolvingZeroProducesError`
Non-root with only autoentities that resolve to 0
`TestNonRootWithDataSourceAndAutoentitiesResolvingEntitiesIsValid`
Non-root with only autoentities resolving > 0 entities
`TestNonRootWithEntitiesAndAutoentitiesResolvingZeroLogsWarning`
Non-root with manual entities + autoentities resolving 0
`TestRootWithNoDataSourceButAutoentitiesProducesError` Root with no
datasource but autoentities defined
`TestRootWithDataSourceAndNoEntitiesProducesError` Root with own
datasource and zero entities/autoentities
`TestRootWithDataSourceAndAutoentitiesResolvingZeroProducesError` Root
with own datasource and autoentities resolving 0
`TestRootWithDataSourceAndAutoentitiesResolvingEntitiesIsValid` Root
with own datasource and autoentities resolving > 0
`TestRootWithEntitiesAndAutoentitiesResolvingZeroLogsWarning` Root with
own datasource, manual entities, and autoentities resolving 0
`TestChildWithDataSourceAndAutoentitiesResolvingZeroProducesNamedError`
Child with autoentities-only resolving 0
`TestChildWithEntitiesAndAutoentitiesResolvingZeroLogsNamedWarning`
Child with manual entities + autoentities resolving 0

Modified tests:

`TestValidateConfigWithNoEntitiesProducesCleanError` Replaced main's
version (expected parse failure) with ours: parse succeeds,
IsConfigValid returns false
`ValidateAutoentitiesConfiguration` Changed to isValidateOnly: true,
asserts no crashes instead of zero errors

---------

Co-authored-by: Anusha Kolan <anushakolan10@gmail.com>
(cherry picked from commit c249436)

…annotation